An investigation into the feasibility, problems and benefits of re-engineering a legacy procedural CFD code into an event driven, object oriented system that allows dynamic user interaction

This paper describes a new solution technique known as the “group solver” -currently under development within the SMARTFIRE Computational Fluid Dynamicsenvironment. The group solver is used to obtain numerical solutions to the algebraicequations associated with fire field modelling. The purpose of the technique is to reduce thecomputational overheads associated with traditional numerical solvers typically used in firefield modelling applications. In the example, discussed in this paper, the group solver isshown to provide a 37% saving in computational time over a traditional solver. INTRODUCTIONIn traditional Computational Fluid Dynamics (CFD) based fire models [1], control ofthe numerical solver applies equally over all of the cells throughout the solution domain. Inlarge geometry cases this can create a significant, and at times limiting, computationaloverhead. This is particularly true in cases where the fire occupies a relatively smallproportion of an otherwise large solution domain for part, or all, of the simulation period.An example of this may be the early stages of fire growth within an airport terminal or aroad/rail tunnel. The group solver concept attempts to address this problem algorithmically,by providing optimal processing in regions of the domain where and when it is required. In the group solver concept, the solution domain is split into an arbitrary number of groups-of-cells. A group is defined as a unique collection of cells that can have solver controlparameters independent from any other groups in the solution domain. Group solvers can beactivated independently for each solved variable. Internally, the group solver makes use ofstandard numerical “point-by-point” solution methods such as JOR or SOR. One way in which this may be achieved is by controlling the number of iterations that thesolver performs in the various groups. For instance, the maximum number of iterations in an“Inactive group” will be considerably smaller than the number for an “Active group”. As thesolution develops, cells can migrate to and from groups, thus receiving more or lesscomputational attention. The overall convergence criteria are still configured as forconventional problems so there should be no significant difference in the quality of theconverged solution. APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-22Previous research on group solver technology focussed on static group membership in atwo-dimensional application [2]. In the remainder of this paper, the SMARTFIRE softwarewill be briefly described followed by a detailed description of the group solver technique.The technique will then be demonstrated for both static and dynamic group membershipthrough the use of a simple three-dimensional fire application. THE SMARTFIRE FIRE FIELD MODEL SMARTFIRE is an open architecture CFD environment with an integrated knowledge basedsystem that attempts to make fire field modelling accessible to non-experts in CFD. Thereare three major components to the software: CFD code, User Interfaces, and Expert System.By embedding expert knowledge into the CFD software, it is hoped that fire field modellingis made more accessible to the fire engineer with limited CFD expertise. The expertisecurrently embedded within the code is used to support the critical task of mesh specificationof fire field simulation scenarios. Expertise is also being developed for the optimalautomated dynamic solution control of fire field simulations during the solution process [3]. The software is fully developed by the University of Greenwich using a combination of in-house and proprietary software building blocks. It is designed to run on PC's under theWIN95/98 or NT operating systems. The minimum computer platform required is a PentiumPC with 32 Mbytes of memory. The primary components of the software have beendescribed previously [2-5] and so will not be repeated here. However, as this paperconcentrates on the CFD engine, this will be briefly outlined here. Figure 1 shows theconceptual architecture of the software and its modules. FIGURE 1: The modular architecture of SMARTFIRE. APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-33The CFD engine of SMARTFIRE, called CWNN++, is written in C++ and has beendeveloped in-house from an existing FORTRAN code [6]. CWNN++ uses validatednumerical methods from the legacy FORTRAN code enhanced by object orienteddevelopments in C++ and additional physics features that are required for fire field modelling[11]. CWNN++ uses three-dimensional unstructured meshes , enabling complex irregulargeometries to be meshed without the need for body fitted co-ordinate grids. Unlikeconventional CFD technology such as PHOENICS [7], FLOW3D [8], JASMINE [9] andSOFHIE [10], this allows extremely complex geometries to be meshed efficiently. The CFD engine is under continual development and evaluation. As part of the testingprocedure, model predictions are compared with other commercial CFD codes and againstdata generated through physical experimentation. Test cases [11] include standard CFDbenchmark cases such as the backward facing step and moving lid problems and the Stecklerroom fire experiments [12]. Results produced by SMARTFIRE for the Steckler experiments[5, 11] compare favourably with those produced using commercial CFD codes such asCFDS-FLOW3D and PHOENICS [13]. The current release of the software is V2.01 [11]. In this version, the software representsfires as a transient volumetric heat and mass source. Standard models for gaseouscombustion (i.e. diffusion and eddy-dissipation models), while not enabled in the generalrelease software, are implemented and undergoing testing. The code uses the SIMPLE [14]algorithm and can solve turbulent (two equation K-Epsilon closure with buoyancymodification) or laminar flow problems under transient or steady state conditions. Radiationis represented through the use of an enhanced six-flux radiation model [11]. Furtherinformation concerning SMARTFIRE including a demonstration may be found on the WorldWide Web [15].BACKGROUND TO GROUP SOLVERSSince SMARTFIRE is a truly unstructured mesh CFD code there are a limitednumber of reliable and general purpose numerical techniques available to solve the systemsof algebraic equations for each of the primary field variables. Structured mesh CFD codescan exploit the structured nature of the data (e.g. using lines or planes) in various solvers togive more efficient solution than for the point-by-point iterative solvers commonly used inunstructured codes. One of the goals of this work has been to investigate and, if possible,exploit reliable techniques that prove to be of benefit to fire modelling within unstructuredmesh CFD codes. One such technique, developed by the authors, is the group solvers. In previous published research [2], it was demonstrated that a multiple region two-dimensional fire scenario could use static group solver techniques to save 31% of theprocessing time. The demonstration consisted of two rooms, one containing a fire , the other(separated by a wall) was initially free of fire or its influence. Under a given set ofconditions, the partition was removed allowing the fire to spread into both compartments.The saving in computational effort was achieved by effectively removing the need to performthe computations for half of the solution domain during part of the simulation, prior to thepartition removal. In this way approximately half of the solution domain was fully de-coupled from the simulation for part of the simulation. This work used the concept of astatic “geometric” group to dictate the solution strategy in each region. Here we APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-44demonstrate the concept of static groups in three-dimensional simulations and extend theconcept to include “dynamic” groups. DESCRIPTION OF GROUP SOLVERS Group solvers are a conceptual extension of the simple linear, iterative, algebraicequation solvers usually referred to as Jaccobi Over Relaxation (JOR) or Successive OverRelaxation (SOR). At the most basic level these solvers involve the repetitive update of thesolution of a property variable within each cell based on the contributions from nearestneighbouring cells, a portion of the previous solution value and the source quantity for eachcell. In a CFD context the contributions from neighbouring cells represent the convectionand/or diffusion of a physical property throughout the solution domain whilst the sourceindicates the creation or destruction of the physical property in the considered cell. Thedistinction between JOR and SOR solvers is that SOR always uses the most up-to-dateversions of the solution when calculating the next update. This can make the SOR solverless stable than the JOR solver but it has the significant advantage of spreading the solutionmuch more rapidly than JOR. In the typical whole-domain JOR or SOR solver, the solution in each and every cell of thedomain is updated repetitively until the difference between successive updates is sufficientlysmall. Clearly, if the solution domain contains many cells that are far removed from anyactive flow region or worse are totally de-coupled from the region of interest for a portion ofthe simulation, then not all of these JOR or SOR calculations are performing any usefuladvancement of the solution. This is especially true of many of the large complex geometriesused in fire field modelling (e.g. whole building simulations). The group solver concept allows the domain to be partitioned into “geometric” or “logical"(i.e. solution dependant) groups of cells that then use the iterative point-by-point updatedescribed above. The difference for the group solvers is that each group can have a uniqueset of control parameters to configure the maximum number of iterations to perform, thetolerance to use for convergence testing and/or the linear solver relaxation to be used. Inthis paper, the investigation only concerns the potential benefits of limiting the number ofiterations that are used within each group of cells – while maintaining the desired level ofconvergence. Since, in an unstructured code, a group does not need to be limited to some pre-configuredgeometric region it is possible to further extend the group solver techniques by allowinggroups to determine their own cell-membership as the solution develops. This has beenimplemented within SMARTFIRE to allow an arbitrary number of groups which can containeither geometric or solution dependant membership (provided that each cell only exists inone group) and that furthermore the dynamic groups can exchange cells as the simulationsolution develops. In practice, the dynamic membership is configured so that each dynamicgroup has an acceptance range of values which will trigger a non-member cell to betransferred into that group if its property value is within the configured range and if the cellis not already contained in another static “geometric” group. The implementation of the group SOR solver requires particular care, at the algorithmiclevel, to ensure that the groups are not de-coupled into JOR connectivity between groups. APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-55This scenario is possible if the looping between group-inner-iterations and between groups ismismanaged. One way this can occur is to give simple external looping for all groups andinternally to loop for all configured group-inner-iterations. There are several possiblemethods of handling group-inner-looping for cases where groups have different numbers ofconfigured inner-iterations. It was decided to interleave the processing between groupswithout using the simplest 1:1 interleave ratio, which while easier to implement could resultin poor efficiency. The more complex interleaving technique, actually used, causes eachgroup to be visited in turn and performs one (or more) of the inner iterations before movingto the next group. The looping amongst groups continues until each group reaches itsconfigured maximum number of inner-iterations or until convergence is detected. In order to attain maximal optimisation for cases with truly de-coupled (and henceuninteresting) group regions, it was also necessary to limit processing of such groups so thatsimple calculated variables are not updated. Mostly there is little difficulty in performing thisoptimisation because the support variables are generally closely linked, in their usage, toassociated solved variables. It should be noted that many of the variables in a fire modelling simulation have a definite“directionality” that can be exploited by matching the marching order of the cells within SORsolvers with this direction. SMARTFIRE has been implemented to use bi-directionalmarching order for all SOR type solvers, which gave a saving of up to 20% over the usualuni-directional marching order when used on the simulation case described in this paper.All of the timings compare bi-directional group and whole-domain SOR solvers. AN APPLICATION OF GROUPS SOLVERS IN A THREE-DIMENSIONAL FIRESCENARIOThe case used to investigate group solvers is a preliminary investigation into firespread between the floors of a multi storey building where window sizes are varied to modifythe ejected plume behaviour. In the case presented here only the lower (ground) floor roomis modelled together with the outer wall of the second and third floors above. In subsequentresearch it is intended that the upper floor rooms will also be fully modelled with windowsthat can be broken by the incident heat flux from the ejected spill plume. In order to investigate the benefits of the group solvers a number of test cases wereprepared. The geometry and mesh used in all of the tests was identical and great care wastaken to ensure that the mesh was sufficiently refined across the height and width of thewindow, near the walls of the room and outside and just above the window. Theseconsiderations are critical to obtaining a reliable and accurate simulation of the ejectedplume. The geometry (see figure 2) was set up with room dimensions of 4.0m (x) X 3.4m (y) X6.0m (z). The centrally located fire is represented as a volumetric heat load which is appliedover a volume of 1.0m X 1.2m X 2.0m. The fire uses an “alpha t squared” power curve,which reaches 2.0 MW (using a fast growth rate) in three minutes of simulated time. Thewindow aperture has a size of 2.0m (y) X 2.0m (z) and is centrally located on the high X-face of the room. The exterior wall, above the window, extends for a height of 10.5mvertically (to allow for the addition of two open rooms above fire room and a further room APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-66height to move the free surface boundary sufficiently far away from any upper floor windowsthat may be used). The extended region beyond the window has the same Z-width as theroom and extends for a distance of 6.0m in the X-direction in order to give ample room forthe plume ejection. All of the surfaces of the extended region have a free surface boundarycondition except for the floor, which is assumed to be solid. The outside region is assumedto be calm prior to the fire. The walls are assumed to be brick with a thickness of 0.1m. Themesh used for the simulation consisted of 40,572 cells with NX=36, NY=49 and NZ=23.The number of cells in the geometric regions was as follows: Dead region ( non participatingrooms above fire compartment i.e. de-coupled region) has 14,260 cells, Fire-room has 8,280cells and the entire extended region has 18,032 cells (see figure 3). FIGURE 2 : The multi-storey geometry used for the group solver tests. The simulation involves buoyancy driven flow with K-Epsilon turbulence model (buoyancymodified) and incorporates the enhanced six-flux radiation model [11]. The entire simulationwas configured to perform 90 time steps of 2 second duration. The solver configurationsused in the various simulations are summerised in table 1. APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-77TABLE 1 : Summary of solver configurations used in simulations.Variable(s) SolverupdatemethodLinearrelaxFalsetimerelaxWholedomainiterations“Active”groupiterations“Calm”groupiterations“Void”groupiterationsPressure SOR 0.6 NA 50 50 12 0Momentum SOR 1.0 0.5 6620Turbulence SOR 1.0 0.1 20 20 50Enthalpy SOR 1.0 2.0 30 30 80Radiation SOR 1.0 0.0 20 20 50 Furthermore all solvers were able to terminate their inner iterations if a commonconvergence level was reached. Each time step was forced to have all normalised variableresiduals converged, to 1.0e-03, before the next time step could be started. FIGURE 3 : Vertical slice through the domain showing the mesh and the various regions. APPENDIX 3 : Conference Paper "The Development and Application of Group Solversin the SMARTFIRE Fire Field Model", Ewer J., Galea E., Patel M. and Knight B.,Proceedings of Interflam '99, Edinburgh, UK, 1999, Vol. 2, pp 939-950. Appendix 11.3Page 143-88For comparison purposes, the following three test cases were simulated: Case 1:The simulation is configured with all solved variables using the whole domain SOR solversas specified in Table 1. For comparison purposes this constitutes the base case. The groupsolvers are not utilised in this test and so the code is run in a conventional manner. Case 2:The entire solution domain is configured into two static “geometric” groups, one groupconfigured as a “Void” group and another configured as an “Active” group (see table 1).The “Void” group contains all of the cells in the decoupled region above the fire room (i.e.14,260 cells or 35.2% of the entire cell buget). The “Active” group contains all of the cellsthat are not in the “Void” group region (i.e. 26,312 cells or 64.8% of the entire cell budget).While the group solvers are activated, group membership remains the same throughout thesimulation. Case 3:The entire solution domain is partitioned into four groups, two are static “geometric” groupsand two are “dynamic” membership groups. The first group is a static group that isconfigured as a “Void” group which contains all of the cells in the de-coupled region abovethe fire room (i.e. 14,260 cells or 35.2% of the entire cell budget). The second “static”group is configured as an “Active” group and contains all of the cells in the fire room, thosein the window aperture and a small rectangular block of cells that is immediately outside ofthe window (uses room with 8,280 cells and 2,366 cells from the extended region i.e. 10,646cells or 26.2% of the entire cell budget). The third group is “dynamic” and “Active” and isconfigured to determine cell membership from the non-static cells of the extended region.The group membership selection criteria is that absolute cell velocity is greater than 10% ofthe maximum domain velocity. The fourth “dynamic” group is configured as a “Calm” groupand contains extended region cells that have an absolute velocity of less than 10% of themaximum domain velocity. The two active groups share the remaining 15,666 extendedregion cells or 38.6% of the entire cell budget. Dynamic group membership is updated every10 sweeps. For the purposes of this paper, timing comparisons based on the first 50 time steps of eachtest will be presented. On the test computer (a Pentium II 400MHz with 256MB of RAM)this gave a convenient processing duration that could be run overnight without interruption.